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DETAILED ACTION 
Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 

eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.114. AppUcant's submission filed on 08/16/2010 has been entered. 

Response to Amendment 

2. Applicant has amended claims 16, 21, 22-24, 26, 27, 29 and 32-34. New claim 37 is 
added. Claim 35 is cancelled. As a result claims 16-34 and 36-37 are pending. 

3. As a result of applicant's amendment, the rejection of claims 32-34 under 35 U.S.C 101 
is withdrawn. 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

5. Claims 16-18, 21-25, 28, 29, 31, 32, 34, and 37 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Rune et al. (US PGPUB 2004/0167988 Al) (herein after Rune) in view 
of O'Neill (US PAT 7,339,903) (herein after O'Neill). 



Application/Control Number: 10/587,979 
Art Unit: 2476 



Page 3 



Regarding claim 16, Rune teaches a method comprising [see paragraphs 0068, 
0069, 0071 and figs. 8-10 where a system and method for bridging a 
Bluetooth scattemet and an Ethernet LAN is shown]: 
checking a destination address of a received packet by an intermediate node 
configured to arrange data transmission between a fist device and a second device 
in a local area networking system, wherein at least the second device is 
configured to multicast and/or broadcast messages [see paragraph 0145 where a 
Network Access Point -herein after 'NAP' (the claimed intermediate node) is 
shown to forward packets between the Bluetooth scatternet and the LAN; see 
paragraph 0196 where when broadcast packets are received, packet filtering 
is performed based on the destination address of the packet]; 
preventing in the system the transmission of the packet to the first device [see 
paragraph 0210 where a broadcast ARP request, encapsulated ARP-route 
request or ARP route request is received at the NAP and where the request 
contains target IP address and where the address filtering function contained 
within the NAP determines whether the address corresponds to an address 
that is stored in the ARP cache; and where the packet is passed to the NAP-B 
(i.e. forwarded to the scattemet from the LAN) unless that is not addressed 
to the NAP itself or the address function determines from the address table 
that the destmation node is located on the receiving side -i.e. the side from 
which the broadcast packet is received]; 
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wherein multicast messages from the first device are forwarded by the 
intermediate node [see paragraph 0214 where broadcast ARP replies received 
from the scattemet (from the first device) are always passed by the address 
filtering fmiction (i.e. the NAP) to the NAP-B because network resource is 
not an issue in the LAN side (second device)]. 

However Rune does not explicitly teach comparing the destination address of the 
packet with at least one predetermined multicast and/or broadcast address and in 
response to the addresses matching/in response to the addresses not matching. 
However, O'Neill teaches if a multicast packet is received, it is determined 
whether or not the address of the multicast packet is in its visitor list; if not, the 
packet is forwarded; if the address matches an address list, the packet is dropped 
[see column 17 lines 42-58]. It would have been obvious for a person having 
ordinary skill in the art to compare the destination address of the packet with at 
least one predetermined multicast and/or broadcast address and preventing the 
packet in response to the addresses matching; and forwarding in response to the 
addresses not matching. This is desirable because it prevents packets from being 
floods to all the sub-networks needlessly (see Rune paragraph 0210). 

Regarding claim 17, Rune teaches the method as claimed in claim 16, wherein 
the intermediate node is configured to connect networks that use different data 
transmission protocols [see paragraphs 0068 and 0069 and fig. 9 where a 
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Network Access Point is used for bridging a Bluetooth scatternet and an 
Ethernet LAN (different data transmission protocols)]. 

Regarding claim 18, Rune teaches a method as claimed in claim 16, wherein the 
destination address is an Internet Protocol address [see paragraph 0210 where a 
broadcast ARP request, encapsulated ARP-route request or ARP route 
request is received at the NAP and where the request contains target IP 
(Internet Protocol) address]. 

Regarding claim 21, Rune teaches a system comprising: a first device; a second 
device; and an intermediate node configured to arrange data transmission between 
the first device and the second device [see paragraphs 0068, 0069, 0071 and 
figs. 8-10 where a system and method for bridging a Bluetooth scatternet and 
an Ethernet LAN is shown where a source device and destination device 
communicate through the NAP (intermediate node)]; 

wherein at least the second device is configured to multicast and/or broadcast 
messages to devices in the system [see paragraphs 0144 and 0145 where a 
Network Access Point -herein after 'NAP' (the claimed intermediate node) is 
shown to forward packets from the LAN to Bluetooth scatternet and where 
the packets are broadcast packets], wherein the system is configured to check 
the destination address of a received packet, wherein the system is configured to 
prevent in the system the transmission of the packet to the first device [see 
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paragraph 0210 where a broadcast ARP request, encapsulated ARP-route 
request or ARP route request is received at the NAP and where the request 
contains target IP address and where the address filtering function contained 
within the NAP determines whether the address corresponds to an address 
that is stored in the ARP cache; and where the packet is passed to the NAP-B 
(i.e. forwarded to the scatternet from the LAN) unless that is not addressed 
to the NAP itself or the address function determines from the address table 
that the destination node is located on the receiving side -i.e. the side from 
which the broadcast packet is received], and wherein the system is configured 
to forward multicast messages from the first device [see paragraph 0214 where 
broadcast ARP replies received from the scatternet (from the first device) 
are always passed by the address filtering function (i.e. the NAP) to the NAP- 
B because network resource is not an issue in the LAN side (second device)]. 
However Rune does not explicitly teach comparing the destination address of the 
packet with at least one predetermined multicast and/or broadcast address and in 
response to the addresses matching/in response to the addresses not matching. 
However, O'Neill teaches if a multicast packet is received, it is determined 
whether or not the address of the multicast packet is in its visitor list; if not, the 
packet is forwarded; if the address matches an address list, the packet is dropped 
[see column 17 lines 42-58]. It would have been obvious for a person having 
ordinary skill in the art to compare the destination address of the packet with at 
least one predetermined multicast and/or broadcast address and preventing the 
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packet in response to the addresses matching; and forwarding in response to the 
addresses not matching. This is desirable because it prevents packets from being 
floods to all the sub-networks needlessly (see Rune paragraph 0210). 



Regarding claim 22, Rune teaches an apparatus [see fig. 9 where a Network 
Access Point -herein after 'NAP' (apparatus) is shown] comprising a processor 
configured to check the destination address of a received packet [see paragraph 
0145 where a Networlt Access Point -herein after 'NAP' is shown to forward 
paclcets between the Bluetooth scatternet and the LAN; see also paragraphs 
0079 and 0247 where a packet filtering function (processor) determines 
whether to block or forward packets ], wherein the apparatus comprises an 
intermediate node configured to arrange data transmission between a first device 
and a second device in a local area networking system; prevent the transmission 
of the packet in the system to the first device [see paragraph 0210 where a 
broadcast ARP request, encapsulated ARP-route request or ARP route 
request is received at the NAP and where the request contains target IP 
address and where the address filtering function contained within the NAP 
determines whether the address corresponds to an address that is stored in 
the ARP cache; and where the packet is passed to the NAP-B (i.e. forwarded 
to the scatternet from the LAN) unless that is not addressed to the NAP itself 
or the address function determines from the address table that the 
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destination node is located on the receiving side -i.e. tlie side from whicli tiie 
broadcast packet is received], wherein the apparatus is configured to forward 
multicast messages from the first device [see paragraph 0214 where broadcast 
ARP replies received from the scattemet (from the first device) are always 
passed by the address filtering function (i.e. the NAP) to the NAP-B because 
network resource is not an issue in the LAN side (second device)]. 

However Rune does not explicitly teach comparing the destination address of the 
packet with at least one predetermined multicast and/or broadcast address and in 
response to the addresses matching/in response to the addresses not matching. 
However, O'Neill teaches if a multicast packet is received, it is determined 
whether or not the address of the multicast packet is in its visitor list; if not, the 
packet is forwarded; if the address matches an address list, the packet is dropped 
[see column 17 lines 42-58]. It would have been obvious for a person having 
ordinary skill in the art to compare the destination address of the packet with at 
least one predetermined multicast and/or broadcast address and preventing the 
packet in response to the addresses matching; and forwarding in response to the 
addresses not matching. This is desirable because it prevents packets from being 
floods to all the sub-networks needlessly (see Rune paragraph 0210). 

Regarding claim 23, Rune teaches the method as claimed in claim 22, wherein 
the processor is configured to cause the apparatus to connect networks that use 
different data transmission protocols [see paragraphs 0068 and 0069 and fig. 9 
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where a Network Access Point is used for bridging a Bluetooth scatternet and 
an Ethernet LAN (different data transmission protocols)]. 

Regarding claim 24, Rune teaches the apparatus according to claim 23 wherein 
the processor is configured to case the apparatus to perform data transmission 
between an IEEE 802- based network to which the second device belongs and a 
Bluetooth network to which the first device belongs [see paragraphs 0068 and 
0069 and fig. 9 where a Network Access Point is used for bridging a 
Bluetooth scatternet and an Ethernet LAN (IEEE 802 based network)]. 

Regarding claim 25, Rune teaches the apparatus according to claim 22, wherein 
the destination address is an Internet Protocol address [see paragraph 0210 
where a broadcast ARP request, encapsulated ARP-route request or ARP 
route request is received at the NAP and where the request contains target IP 
(Internet Protocol) address]. 

Regarding claim 28, Rune teaches the apparatus according to claim 22, wherein 
the data processor configured to check, in addition to the comparison of the 
destination address of the packet with at least one predetermined multicast and/or 
broadcast address, if the packet complies with one or more further message 
transmission conditions, and the processor is configured to allow forwarding of 
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the message to the first device in response to the message complying with the one 
or more further message transmission conditions [See paragraph 0196 lines 10- 
21 where packet filtering is based on destination address and NAL packet 
type and based on higher layer protocols (one or more further message 
transmission conditions)]. 



Regarding claim 29, Rune teaches an apparatus [see fig. 9 where a Network 
Access Point -herein after 'NAP' (apparatus) is shown] comprising: a 
processor configured to check a destination address of a received packet, prevent 
transmission of the packet to a first device [see paragraph 0145 where a 
Network Access Point -herein after 'NAP' is shown to forward packets 
between the Bluetooth scatternet and the LAN; see also paragraphs 0079 and 
0247 where a packet filtering function (processor) determines whether to 
block or forward packets; See also paragraph 0210 where a broadcast ARP 
request, encapsulated ARP-route request or ARP route request is received at 
the NAP and where the request contains target IP address and where the 
address filtering function contained within the NAP determines whether the 
address corresponds to an address that is stored m the ARP cache; and 
where the packet is passed to the NAP-B (i.e. forwarded to the scatternet 
from the LAN) unless that is not addressed to the NAP itself or the address 
function determines from the address table that the destination node is 
located on the receiving side -i.e. the side from which the broadcast packet is 
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received ], wherein the apparatus is configured to forward multicast messages 
from the first device [see paragraph 0214 where broadcast ARP replies 
received from the scattemet (from the first device) are always passed by the 
address filtering function (i.e. the NAP) to the NAP-B because network 
resource is not an issue in the LAN side (second device)]. 
However Rune does not explicitly teach comparing the destination address of the 
packet with at least one predetermined multicast and/or broadcast address and in 
response to the addresses matching/in response to the addresses not matching. 
However, O'Neill teaches if a multicast packet is received, it is determined 
whether or not the address of the multicast packet is in its visitor list; if not, the 
packet is forwarded; if the address matches an address list, the packet is dropped 
[see column 17 lines 42-58]. It would have been obvious for a person having 
ordinary skill in the art to compare the destination address of the packet with at 
least one predetermined multicast and/or broadcast address and preventing the 
packet in response to the addresses matching; and forwarding in response to the 
addresses not matching. This is desirable because it prevents packets from being 
floods to all the sub-networks needlessly (see Rune paragraph 0210). 

Regarding claim 31, Rune teaches the apparatus according to claim 29, wherein 

the processor is configured to compare one or more properties of the message to 
properties specified in predetermined transmission conditions to determine 
whether the message should be transferred to the first device [see paragraph 
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0210 where a broadcast ARP request, encapsulated ARP-route request or 
ARP route request is received at the NAP and where the request contains 
target IP address and where the address filtering function contained within 
the NAP determines whether the address corresponds to an address that is 
stored in the ARP cache; and where the packet is passed to the NAP-B (i.e. 
forwarded to the scatternet from the LAN) unless that is not addressed to the 
NAP itself or the address function determines from the address table that the 
destination node is located on the receiving side -i.e. the side from which the 
broadcast packet is received]. 

Regarding claim 32, Rune teaches a memory storing a computer program [see 
paragraph 0077 lines 14-20 where a NAP is implemented on a software 
(computer readable storage medium), hardware or a combination of both], 
the computer program configured to control a processor to perform the following: 
checking a destination address of a received packet, preventing transmission of 
the packet in the system to a first device; and forwarding multicast messages from 
the first device [see paragraph 0210 where a broadcast ARP request, 
encapsulated ARP-route request or ARP route request is received at the 
NAP and where the request contains target IP address and where the address 
filtering function contained within the NAP determines whether the address 
corresponds to an address that is stored in the ARP cache; and where the 
packet is passed to the NAP-B (i.e. forwarded to the scatternet from the 
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LAN) unless that is not addressed to the NAP itself or the address function 
determines from the address table that the destination node is located on the 
receiving side -i.e. the side from which the broadcast packet is received]. 

However Rune does not explicitly teach comparing the destination address of the 
packet with at least one predetermined multicast and/or broadcast address and in 
response to the addresses matching/in response to the addresses not matching. 
However, O'Neill teaches if a multicast packet is received, it is determined 
whether or not the address of the multicast packet is in its visitor list; if not, the 
packet is forwarded; if the address matches an address list, the packet is dropped 
[see column 17 lines 42-58]. It would have been obvious for a person having 
ordinary skill in the art to compare the destination address of the packet with at 
least one predetermined multicast and/or broadcast address and preventing the 
packet in response to the addresses matching; and forwarding in response to the 
addresses not matching. This is desirable because it prevents packets from being 
floods to all the sub-networks needlessly (see Rune paragraph 0210). 

Regarding claim 34, Rune teaches a memory according to claim 32, wherein the 
computer program is further configured to control the processor to compare one 
or more properties of the message to properties specified in predetermined 
transmission conditions to determine whether the message should be transferred 
to the first device [see paragraph 0210 where a broadcast ARP request, 
encapsulated ARP-route request or ARP route request is received at the 
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NAP and where the request contains target IP address and where the address 
filtering function contained within the NAP determines whether the address 
corresponds to an address that is stored in the ARP cache; and where the 
packet is passed to the NAP-B (i.e. forwarded to the scattemet from the 
LAN) unless that is not addressed to the NAP itself or the address function 
determines from the address table that the destination node is located on the 
receiving side -i.e. the side from which the broadcast packet is received]. 



Regarding claim 37, Rune teaches a method comprising: checking a destination 
address of a received packet; determining whether the destination address of the 
packet is a predetermined multicast and/or broadcast address; preventing the 
transmission of the packet to a first device [see paragraph 0210 where a 
broadcast ARP request, encapsulated ARP-route request or ARP route 
request is received at the NAP and where the request contains target IP 
address and where the address filtering function contained within the NAP 
determines whether the address corresponds to an address that is stored in 
the ARP cache; and where the packet is passed to the NAP-B (i.e. forwarded 
to the scatternet from the LAN) unless that is not addressed to the NAP itself 
or the address function determines from the address table that the 
destination node is located on the receiving side -i.e. the side from which the 
broadcast packet is received]; and forwarding multicast and/or broadcast 
messages to at least the first device [see paragraph 0214 where broadcast ARP 
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replies received from the scatternet (from the first device) are always passed 
by the address filtering function (i.e. the NAP) to the NAP-B because 
network resource is not an issue m the LAN side (second device)]. 

However Rune does not explicitly teach comparing the destination address of the 
packet with at least one predetermined multicast and/or broadcast address and in 
response to the addresses matching/in response to the addresses not matching. 
However, O'Neill teaches if a multicast packet is received, it is determined 
whether or not the address of the multicast packet is in its visitor list; if not, the 
packet is forwarded; if the address matches an address list, the packet is dropped 
[see column 17 lines 42-58]. It would have been obvious for a person having 
ordinary skill in the art to compare the destination address of the packet with at 
least one predetermined multicast and/or broadcast address and preventing the 
packet in response to the addresses matching; and forwarding in response to the 
addresses not matching. This is desirable because it prevents packets from being 
floods to all the sub-networks needlessly (see Rune paragraph 0210). 

6. Claims 19,20,26,27,30 and 33 rejected under 35 U.S.C. 103(a) as being unpatentable over 
Rune as applied to claims 16-18, 21-25, 28,29,31, 32,34 and 37 above and further in view of 
Vasisht (US 2004/0133689). 



Regarding claim 19, Rune teaches a method as claimed in claim 16 as discussed 
above. However, Rune does not explicitly teach the first device belongs to a 
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Mobile Handheld Subcommittee domain of a Universal Plug and Play system and 
the second device belongs to a Home Network version 1 domain of the Universal 
Plug and Play system. However, Vasisht teaches using UPnP in one of the 
networks [paragraph 0051 line 24]. It would have been obvious for a person 

having ordinary skill in the art to utilize UPnP (various versions include MRS and 
Home network version) in one of the networks. UPnP (both the Home network 
and MHS versions) is desirable because it allows devices to connect seamlessly. 

Regarding claim 20, Rune teaches a method as claimed in claim 19 including 
preventing multicast messages to the first device as discussed above. However, 
Rune does not explicitly teach Universal Plug and Play-UPnP. However, Vasisht 
teaches using UPnP in one of the networks [paragraph 0051 line 24]. It would 
have been obvious for a person having ordinary skill in the art to utilize UPnP in 
one of the networks. UPnP is desirable because it allows devices to connect 
seamlessly. 

Regarding claim 26, Rune teaches the apparatus according to claim 22 as 
discussed above. However, Rune does not explicitly teach the first device belongs 
to a Mobile Handheld Subcommittee domain of a Universal Plug and Play system 
and the second device belongs to a Home Network version 1 domain of the 
Universal Plug and Play system. However, Vasisht teaches using UPnP in one of 
the networks [paragraph 0051 line 24]. It would have been obvious for a person 
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having ordinary skill in the art to utilize UPnP (various versions include MHS and 
Home network version) in one of the networks. UPnP (both the Home network 
and MHS versions) is desirable because it allows devices to connect seamlessly. 

Regarding claim 27, Rune teaches the apparatus according to claim 25, wherein 

the processor is configured to prevent transmission of universal plug and play 
discovery multicast message to the first device, and the apparatus is configured to 
forward at least the broadcast messages relating to the address definition to the 
first device. However, Vasisht teaches using UPnP in one of the networks 
[paragraph 0051 line 24]. It would have been obvious for a person having 
ordinary skill in the art to utilize UPnP (various versions include MHS and Home 
network version) in one of the networks. UPnP (both the Home network and MHS 
versions) is desirable because it allows devices to connect seamlessly. 

Regarding claim 30, Rune teaches the apparatus according to claim 29 wherein 
the processor is configured to prevent transmission of universal plug and play 
discovery multicast messages to the first device. However, Vasisht teaches using 
UPnP in one of the networks [paragraph 0051 line 24]. It would have been 
obvious for a person having ordinary skill in the art to utilize UPnP (various 
versions include MHS and Home network version) in one of the networks. UPnP 
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(both the Home network and MHS versions) is desirable because it allows devices 
to connect seamlessly. 



Regarding claim 33, Rune teaches a memory according to claim 32, wherein the 
computer program is further configured to control the processor to prevent 
transmission of universal plug and play discovery multicast messages to the first 
device. However, Vasisht teaches using UPnP in one of the networks [paragraph 
0051 line 24]. It would have been obvious for a person having ordinary skill in 
the art to utilize UPnP (various versions include MHS and Home network 
version) in one of the networks. UPnP (both the Home network and MHS 
versions) is desirable because it allows devices to connect seamlessly. 



7. Claim 36 is rejected under 35 U.S.C. 103(a) as being unpatentable over Rune as applied 
to claims 16,18,21,22,25,28,29,31,32,34 and 35 above, and further in view of Tung (US 
2006/0136562 Al) (herein after Tung). 

Regarding claim 36, Rune teaches the apparatus according to claim 22 as discussed 

above. However, Rune does not explicitly teach the processor is configured to check 
whether the first device is in sleep mode and, when the first device is in sleep mode, the 
processor is configured to wake up the first device before transmitting a message to the 
first device. However, Tung in the same field of endeavor teaches a network node such as 
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a multimedia server that operates in sleep mode and is only activated when receiving a 
request [see paragraph 0006 and paragraph 0002]. It would have been obvious for a 
person having ordinary skill in the art, at the time of the invention, to check whether the 
nodes in Rune are in sleep mode and when it is in sleep mode wake up the node before 
transmitting a message to the server. This is desirable because it provides for power 
savings. 

Response to Arguments 

8. Applicant's arguments with respect to claims 16-34 and 36-37 have been considered but 
are moot in view of the new ground(s) of rejection. 

Conclusion 

Any inquiry concerning this communication or earUer communications from the 
examiner should be directed to SORI A. AG A whose telephone number is (571)270-1868. The 
examiner can normally be reached on M-F 7:30-4:00. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Ayaz R. Sheikh can be reached on (57 1)272-3795. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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